Remarks 



Claims 1, 2 and 4-20 are pending in this application. Claims 1, 2 and 4-7 stand 
rejected under 102(e) by Berg et al. (U.S. Patent Publication No. 2002/0188481; 
hereafter "Berg*). Claim 3 has been canceled. Claims 1, 2 and 5-7 have been 
amended. New claims 8-20 have been added. Support for the amendments may be 
found on page 4 lines 16-20, page 5 lines 5-10, page 11 lines 8-1 1 , page 12 lines 4-7 
and page 14 lines 4-7. The prior art rejections are addressed below. 

Rejections under 35 U.S.C. 102 

Claims 1-7 were rejected under 35 (JSC 102(e) as being anticipated by Berg. 
These rejections are respectfully traversed. 

Berg is generally directed toward a method for insurance claims processing, and 
more particularly, providing insurance coverage for online transactions. Specifically, 
Berg generates and provides a financial product which can provide insurance coverage 
"guaranteeing" the identity or financial viability of a user (or trading counterpart) and/or 
the completion of a transaction with a trading counterpart [0002]. The insurance 
coverage provides, in exchange for payment of a premium, assurance against the event 
that a user has been misidentified [0012], [0033]. Thus, rather than authenticating or 
positively identifying a User, Berg provides an online insurance product that provides 
compensation for when a user has been misidentified. 

The system of Berg discloses various "entities" including: users (20) (e.g., 
marketplaces, buyers, sellers); a JV Authority (30); a Registration Authority (40); a 
Credential Issuing Authority (50); etc. (see, Figure 1). In operation, users (20) initially 
submit identifying information to a Joint Venture (JV) Authority (30). The JV Authority 
(30) processes the identifying information with information contained in a database of 
business information providers for verification [0007], [0063]. The JV authority (30) may 
be a business information provider such as Dun & Bradstreet, or may itself be a 
business information provider, the business information provider may provide 
information such as: contact information, financial risk assessment, financial viability, 
credit-worthiness, credit score, profitability, etc. [0005], [0006]. After verification is 
complete, the JV Authority (30) sends information regarding the user (20) to a 
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Registration Authority (40) that can register the verified user (20) and request security 
credentials from a Credential Issuing Authority (50) [0007], [0017]. 

Regarding claim 1 : 

Berg does not teach wherein the User does not require use of software 
received from the Central-Entity to employ digital identity that includes a dynamic, 
non-predictable and time dependent SecureCode as set forth in claim 1 . Instead, 
Berg discloses a security credential, or unique identifier, that may take the form of: a 
user name, password, digital certificate, or alphanumeric identifier [0037]. However, the 
user name, password or alphanumeric identifier issued by Berg do not include a 
SecureCode that is dynamic, non-predictable and time dependent. Furthermore, the 
digital certificates of Berg do not meet the claimed limitation wherein the User does not 
require use of software received from the Central-Entity to employ digital identity. This is 
because digital certificates comprise files that are downloaded and/or installed on a 
user's computer: In paragraphs [0007] and [001 1], Berg even states that the digital 
certificates may be "downloaded and temporarily stored on any computer being used by 
a user" to verify identity and to facilitate subsequent interaction with trading counterparts 
(emphasis added). 

Berg also does not disclose that the seller forwards digital identity received 

from the User to the Central-Entity, the applicants' have been unable to find this 

feature in the paragraphs cited in the Office Actions. The applicants' requested that the 

Office specifically show where these features are necessarily present in Berg in the 

response filed (09/19/2006), however to date, no such evidence has been provided. 

Instead, in the Advisory Action paper number 20061010, the Office asserts that: 

"Berg discloses that the JV Authority (i.e., Central-Entity) can process information 
(i.e., verifying identify) submitted by a user (i.e., External-Entity or a seller) in 
conjunction with information provided by a business information provider (i.e., 
another trusted entity) to verify the identity and/or financial viability of a trading 
counterpart or user (i.e., a buyer or requester). This implies that the seller has 
received the buyer identity from the buyer before submitting to the JV Authority. 
Thus, the disclosures of Berg system meet the limitations of the instant 
independent claims. 0 

The applicants' respectfully disagree. For one, the business information provider 
is not the same as the seller. In other words, the buyer is not performing e- 
commerce with the business information provider. Furthermore, nowhere does 
Berg explicitly teach or even imply that the seller (i.e., the Extemal^Entrty) 
offering goods or services receives the security credentials or unique identifier 
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from the buyer and then submits it to the JV Authority. Rather, the buyer 
provides his unique identifier to the 'Central-Entity,* or JV Authority, "a user ... 
can access the instant invention by providing such credentials 10 or identifier to 
the joint venture authority database." See paragraph [0064]. Even more, Berg 
clearly illustrates the unique identifier being provided to the JV Authority (or JV 
Authority database) by means of the dotted line shown in Figure 1 (see [0084]). 
In Figure 2, Berg again distinctly shows the buyers and sellers each submitting 
their security credentials to the JV Authority by dotted lines 7 and 8. See [0066]. 
Thus, nowhere does Berg teach or even suggest the buyer providing his security 
credentials (as indicated by a dotted line) to the seller. Again, in Figure 3, 
previously verified users provide their unique identifiers to the joint venture 
authority (JV) 140. See [0067]. 

Furthermore, applicants' submit the Office's statement that it is implied that the 
seller has received the buyer identity from the buyer before submitting it to the JV 
authority is not a prima facie 102(e) rejection. A rejection based upon inherent or 
implied disclosure is improper and unsupportable absent any basis in fact and/or 
technical reasoning to reasonably support the determination that the "inherent" 
characteristic necessarily flows from the teachings of the applied prior art. Ex parte 
Levy, 17 USPQ 2d 1461, 1464 (Bd. Pat. App. & Inter. 1990) (emphasis in original). See 
MPEP§2112. 

Regarding claim 2 : 

Berg does not disclose a digital identity that includes a SecureCode and other 
user-specific information. Instead, Berg discloses that the unique identifier or security 
credential may take the form of: a user name, password, digital certificate, or 
alphanumeric identifier [0037]. 

Regarding claim 5 : 

Berg does not teach a dynamic, non-predictable and time dependable 
SecureCode as set forth in claim 5. Berg discloses a security credential, or unique 
identifier, may take the form of: a user name; password; digital certificate; or 
alphanumeric identifier [0037]. However, the user name, password or alphanumeric 
identifier issued by Berg do not include a SecureCode that is dynamic, non-predictable 
and time dependent. Furthermore, the digital certificates of Berg do not meet the 
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claimed limitation wherein the User does not require use of software received from the 

Central-Entity to employ digital identity. This is because digital certificates comprise files 

that are downloaded and/or installed on a user's computer. In paragraphs [0007] and 

[001 1], Berg even states that the digital certificates may be "downloaded and temporarily 

stored on any computer being used by a user" to verify identity and to facilitate 

subsequent interaction with trading counterparts (emphasis added). 

Additionally, Berg foils to disclose method steps where: The External-Entity 

requests the user to authenticate himself using his digital identity," The user 

submits his SecureCode as part of the digital identity in response to External 

Entity's request," and 'The External-Entity forwards the user's digital identity ... to 

the Central-Entity" (emphasis added). Nowhere in the disclosure of Berg can 

applicants' find the method steps where the seller actively a requests" the buyer to 

authenticate himself; where the buyer actively "submits" his SecureCode as part of the 

digital identity "in response to" the seller's request; and where the seller actively 

"forwards" the digital identity to the JV Authority. This is not surprising because all 

communication between the buyer and seller takes place via the intermediate 

marketplace (see e.g., figures 1-3). The applicants' have been unable to find this feature 

in the paragraphs cited in the Office Actions. The applicants' requested that the Office 

specifically show where these features are necessarily present in Berg in the response 

filed (09/19/2006), however to date, no such evidence has been provided. Instead, in 

the Advisory Action paper number 20061 01 0, the Office asserts that: 

"Berg discloses that the JV Authority (i.e., Central-Entity) can process information 
(i.e., verifying identity) submitted by a user (i.e., External-Entity or a seller) in 
conjunction with information provided by a business information provider (i.e., 
another trusted entity) to verify the identity and/or financial viability of a trading 
counterpart or user (i.e., a buyer or requester). This implies that the seller has 
received the buyer identity from the buyer before submitting to the JV Authority. 
Thus, the disclosures of Berg system meet the limitations of the instant 
independent claims. 9 

The applicants' respectfully disagree. For one, the business information provider 
is not the same as the seller. In other words, the buyer is not performing e- 
commerce with the business information provider. Furthermore, nowhere does 
Berg explicitly teach or even imply that the seller (i.e., the External-Entity) 
offering goods or services receives the security credentials or unique identifier 
from the buyer and then submits it to the JV Authority. Rather, the buyer 
provides his unique identifier to the "Central-Entity," or JV Authority: "a user ... 
can access the instant invention by providing such credentials 10 or identifier to 
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the joint venture authority database." See paragraph [0064]. Even more, fferg 
clearly illustrates the unique identifier being provided to the JV Authority (or JV 
Authority database) by means of the dotted line shown in Figure 1 (see [0064]). 
In Figure 2, Berg again distinctly shows the buyers and sellers each submitting 
their security credentials to the JV Authority by dotted lines 7 and 8. See [0066]. 
Thus, nowhere does Berg teach or even suggest the buyer providing his security 
credentials (as indicated by a dotted line) to the seller. Again, in Figure 3, 
previously verified users provide their unique identifiers to the joint venture 
authority (JV) 140. See [0067] 

Furthermore, applicants' submit the Office's statement that it is implied that the 
seller has received the buyer identity from the buyer before submitting it to the JV 
authority is not a prima facie 102(e) rejection. A rejection based upon inherent or 
implied disclosure is improper and unsupportable absent any basis in fact and/or 
technical reasoning to reasonably support the determination that the "inherent" 
characteristic necessarily flows from the teachings of the applied prior art. Ex parte 
Levy, 17 USPQ 2d 1461, 1464 (Bd. Pat. App. & Inter. 1990) (emphasis in original). See 
MPEP§2112. 

Thus unlike the passwords, user names, and alphanumeric identifiers disclosed 
by Berg, the present invention provides digitial identity-based authentication where the 
digital identity includes a SecureCode that is dynamic, non-predictable and time 
dependent. Further, unlike digital certificates which are stored on a user's computer, 
digital identity does not require the use of software received from a Central-Entity. For 
example, the digital identity is calculated based on the SecureCode and user-specific 
information. 

To anticipate a claim, a reference must teach each and every element off the 
claim: "[a] claim is anticipated only if each and every element as set forth in the claim is 
found, either expressly or inherently described, in a single prior art reference." Verdegaal 
Bros. v. Union Oil Co. of California, 814 F.2d 628, 631, 2 USPQ2d 1051 , 1053 (Fed. Cir. 
1987). See MPEP 2131. Applicants' maintain that Berg fails to anticipate each and 
every element of the claims as is the statutory threshold for a prima facie rejection under 
35 U.S.C. § 102(e). Accordingly, applicants' submit that claims 1 and 5, and their 
dependents, as well as new claims 8-20 are allowable over the prior art of record. 
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Conclusion 



The applicants' respectfully request reconsideration of the claim rejections based 
on the above amendments and remarks. It is believed that a full and complete response 
has been made to the outstanding Office Action, and as such, the present application is 
in condition for allowance. If the examiner believes that personal communication will 
expedite prosecution of this application, the Examiner is invited to telephone the 
undersigned at (571) 228-2938. 

In response to the previous Office Action, the applicants' have further submitted 
a 2-month extension of time fee as required by § 1.17(a). 



Respectfully submitted, 

Dated: 11/20/2006 




Shawna J. St 
Agent for Applicants 
Registration No. 57,091 
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